feat(extraction): exclude FM-Agent's work directory by default - #7
Merged
Conversation
FM-Agent writes fm_agent/ into the project it analyses. It holds one copy of every function extracted from that project plus the scripts staged to produce them, so indexing it lists each function twice and mixes tool code in with project code - on a four-function Python project, 43 of 47 function nodes. Add `fm_agent` to DEFAULT_IGNORE_DIRS. Unlike the entries around it this name is not from the github/gitignore templates and could plausibly be real source, which is why upstream would not carry it; a project that does own an fm_agent/ directory opts back in with a `.gitignore` negation, as for any other default-ignored directory. The supported way to express this is an `exclude` entry in the project's codegraph.json, which is what FM-Agent does today. It works, but it means FM-Agent creates a file in a repository it does not own, on every project it analyses, purely to describe its own artifacts. Carrying the exclusion in the build it already pins removes that: nothing is written outside FM-Agent's own work directory. The codegraph.json write stays until the pinned fork build is guaranteed to be the one running, since an upstream build has no other mechanism. Measured on a project holding fm_agent/ with neither codegraph.json nor .gitignore: 79 nodes before, 6 after - and 79 again with `!fm_agent/` in .gitignore. FORK.md now records the patch in a table, states that each one must be re-applied on every upstream sync, and names the real pinned base (upstream main c6aaa20, which is past v1.5.0) alongside why the version marker still reads 1.5.0-fmagent.N. The policy paragraph is brought in line with what the last sync actually did: merging an untagged upstream commit is allowed when what we need is unreleased, and then the verification burden is ours. Version bumped to 1.5.0-fmagent.2.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
FM-Agent writes
fm_agent/into the project it analyses — one copy of everyextracted function, plus the scripts staged to produce them — so indexing it
lists each function twice and mixes tool code in with project code. On a
four-function Python project that is 43 of 47 function nodes.
Adds
fm_agenttoDEFAULT_IGNORE_DIRS, and bumps the version to1.5.0-fmagent.2.Why this is fork-only
Upstream's list is curated from the github/gitignore templates, and the comment
above it says names that could plausibly be first-party source are deliberately
left out.
fm_agentis such a name, so it stays here rather than going upstream.A project that does own an
fm_agent/directory opts back in with a.gitignorenegation, exactly as for
vendor/or any other default-ignored directory.Why not
codegraph.jsonThe supported way to express this is an
excludeentry in the project'scodegraph.json, and FM-Agent does exactly that today. It works — but it meansFM-Agent creates a file in a repository it does not own, on every project it
analyses, purely to describe its own artifacts.
Carrying the exclusion in the build FM-Agent already pins removes that: nothing
gets written outside FM-Agent's own work directory. The
codegraph.jsonwritestays for now, since a build that is not this fork has no other mechanism — it can
be dropped once the pinned build is guaranteed to be the one running.
Verification
A project holding
fm_agent/, with neithercodegraph.jsonnor.gitignore:src/app.py)!fm_agent/in .gitignorenpm run buildpasses;npm testis 2901 passed, 0 failed — unchanged from thebase. codegraph-benchmark passes 4/4 against this build (one regression case,
three baseline cases).
FORK.md
The fork carried no code patch until now, so the file said so. It now lists this
one in a table with a note that each patch must be re-applied on every upstream
sync — that list is what catches a merge silently dropping one.
It also records the real pinned base: upstream
mainatc6aaa20, which is pastv1.5.0, and why the version marker still reads1.5.0-fmagent.N. The policyparagraph is brought in line with what the last sync actually did — merging an
untagged upstream commit is allowed when what we need is unreleased, with the
verification burden on us.